典型网络故障：长连接与短连接选择及 TIME_WAIT 优化

0. 引言

"为什么 netstat 里有几万个 TIME_WAIT？""该用长连接还是短连接？"——这是后端与运维面试的高频题，也是线上真实故障的常见源头。本章按四个模块展开：长连接与短连接的原理、各自的应用场景、TIME_WAIT 与 TCP 连接的关系，以及系统层面的优化方案。

1. 什么是长连接和短连接

• 短连接：每次传输数据前建立一次连接通道，传完即关；传第二份数据时重新建连；
• 长连接：建立一条连接通道并保持，多次传输复用同一条通道。

1.1 建立长连接的两个前提

1. 客户端使用长连接方式请求：客户端不能主动断开，要复用连接传输数据；
2. 服务端支持长连接：在连接周期内不主动断开，支持客户端请求模式。

以 Nginx 为例：

keepalive_timeout 0;      # 关闭长连接，仅支持短连接
keepalive_timeout 120s;   # 支持 2 分钟的长连接

通过浏览器开发者工具可验证：Request Headers 与 Response Headers 中 Connection: keep-alive 表示双向建立了长连接。

2. HTTP 协议与连接模型演进

HTTP/1.1 下请求 index.html、aa.css、bb.js 必须串行：一个请求完成后才能发起下一个；HTTP/2.0 可以在同一条 TCP 连接上同时发起多个请求、并行接收响应，这就是多路复用（Multiplexing）。

3. 长连接与短连接的优劣对比

选择逻辑：大部分 Web 服务与 API 用短连接；长连接集中用于三类场景——数据库连接池（固定数量的连接通道）、聊天室（双向通信）、消息推送（服务端主动下发）。

4. TIME_WAIT 的产生与影响

4.1 产生机制：TCP 四次挥手

主动关闭方发出 FIN → 被动方回 ACK → 被动方再发 FIN+ACK → 主动方回 ACK 后进入 TIME_WAIT 状态。

四次挥手理论上已完成，为何还要保留 TIME_WAIT？——TCP 协议需要保证最后一次 ACK 的稳定性：若 ACK 丢失，需要重发；同时确保旧连接的数据包不会串扰新连接。

4.2 大量 TIME_WAIT 的影响

• 占用文件句柄、内存与端口；
• 系统会回收过多的 time-wait socket，网络条件不佳时可能导致数据包重复发送；
• 通常不会直接造成连接失败，但会带来资源占用与新建连接的风险。

5. TIME_WAIT 优化方案

5.1 加大 TIME_WAIT 队列容量

sysctl -w net.ipv4.tcp_max_tw_buckets=200000

在系统资源允许的前提下调高 tcp_max_tw_buckets，增大缓冲容量，避免操作系统过早回收连接。

5.2 缩短回收时间

sysctl -w net.ipv4.tcp_fin_timeout=30

tcp_fin_timeout 控制 TIME_WAIT 的等待时长，调小可更快释放资源；但不宜过小，否则 TIME_WAIT 的保序意义消失。30 秒是实践中比较合理的取值。

5.3 优化原则

• 先评估连接数规模与资源水位，再决定是否调参；
• 更根本的优化是减少连接数：服务端合理配置 keepalive 复用连接、客户端使用连接池；
• 内核参数修改后写入 /etc/sysctl.conf 持久化，并 sysctl -p 生效。

6. 小结

• 长短连接的本质：短连接每次建连传完即断，长连接复用通道持续传输；选型取决于建连开销与探活开销的权衡；
• HTTP 演进：1.0 不支持长连接 → 1.1 串行长连接 → 2.0 多路复用；
• TIME_WAIT 是协议特性：由四次挥手产生，保证最后一次 ACK 稳定，数量大可调优但不可归零；
• 优化两步走：tcp_max_tw_buckets 加大容量、tcp_fin_timeout=30 缩短周期，配合连接池从源头减少连接数。

下一章进入网络故障分析专题：ping、mtr、traceroute 与 tcpdump 抓包诊断的完整方法。